6.3.1 -
Le partage des
fichiers :
6.3.1.A - Les serveurs de fichiers
Microsoft :
L’ensemble des vulnérabilités des systèmes
d’exploitation Microsoft Windows NT et Windows 2000 sont également
valables dans la version serveur de ces systèmes d’exploitation. Il
est à noter que Microsoft annonce que la nouvelle version de ses
systèmes d’exploitation serveurs « .NET » a
été entièrement redéveloppée de
manière a prendre en compte les aspects de sécurité
dès la conception du dit système d’exploitation. Il est
important de se rappeler que ce discours avait déjà
été tenu lors de la sortie de Windows 2000 avec pour bilan
que 80% des patchs de sécurité de Windows NT4 étaient
également valables pour Windows 2000 : ceci semble bien traduire la
notion de réécriture prônée par
Microsoft !!!
6.3.1.B - Les serveurs de fichiers
UNIX :
6.3.1.B.1 - NFS :
NFS est un protocole permettant à plusieurs machines en
réseau de partager des fichiers localisés sur différents
sites, ce qui va, par exemple, permettre à de petites stations de travail
d’accéder aux capacités disques d’un serveur plus
imposant.
Par l’intermédiaire de NFS, un système de
fichier du serveur est utilisé comme un système de fichier local.
NFS permet de centraliser l’administration des disques et des
systèmes de fichiers supportés. Tout comme NIS/YP, NFS est
construit sur le protocole RPC. Le mode de fonctionnement implique
l’initialisation des processus démons sur les machines du
réseau.
Les principaux démons liés à
l’activité de NFS sont :
- biod, qui se charge des entrées/sorties,
- rpc.lockd et rpc.statd qui gèrent le verrouillage des fichiers,
- rpc.mountd et nfsd qui assurent les services NFS. Le démon nfsd
reçoit les requêtes RPC et les exécute sur le
serveur.
L’exportation des systèmes de fichiers est
décrite dans le fichier « /etc/exports » (sous Unix)
et elle est assurée par la commande exportfs, qui permet de rendre ces
systèmes de fichiers disponibles aux clients en fonction de leurs droits
respectifs, également définis dans le fichier
« /etc/exports ».
6.3.1.B.1.a - Problèmes de
sécurité :
Le principal problème de sécurité de NFS tient
à sa faible authentification des requêtes. L’accès au
système de fichiers exporté par NFS ne permet pas une
granularité fine des droits : soit une machine cliente est
autorisée à accéder au système de fichiers, soit
elle n’en a pas le droit.
A partir du moment où le serveur va se
fier à une machine cliente, il acceptera tout ce que le client lui
donnera comme information pour se connecter. Le serveur va alors utiliser ces
informations pour gérer les autorisations de la même façon
que le fait Unix.
Le mécanisme de vérification du client est
simple. Une machine cliente envoie une requête au serveur pour monter un
système de fichiers exporté. Le serveur va alors vérifier,
à partir de l’adresse IP de la machine, si celle-ci est
autorisée à accéder à ce système de fichier.
Si la réponse est positive, le serveur fournit au client une clé
d’autorisation, qui dépend du système de fichiers
exporté, qui sera utilisé pour les accès du client aux
fichiers.
A chaque action entreprise par le client, une requête est
envoyée au serveur avec la description de l’action et
l’autorisation du client.
Tout cela pose différents
problèmes de sécurité :
- Le serveur NFS se fie à l’adresse IP de la machine cliente pour
son authentification, ce qui le rend vulnérable aux falsifications
d’adresse,
- Le serveur NFS se fie au client pour identifier l’utilisateur, ce qui
le rend vulnérable à un agresseur qui aurait infiltré une
machine cliente,
- Le serveur ne revérifie jamais l’authenticité du client
à chaque requête. Ainsi, un agresseur qui se serait fabriqué
une clé d’autorisation valide, ou qui aurait réussi à
en capturer une, pourrait accéder au système de fichier de la
même façon qu’un utilisateur dûment
autorisé.
La méthode de génération des
autorisations est prévisible, car elle dépend de la date de
création du système de fichiers. Comme la plupart des serveurs NFS
autorisent un certain nombre d’essais infructueux sans se plaindre, un
agresseur peut deviner sans trop de difficultés l’autorisation
nécessaire pour se connecter à ce système de fichier. Plus
le système de fichiers est récent, plus la recherche de
l’autorisation est facile.
Une fois que l’autorisation a
été trouvée par un agresseur, celui-ci pourra venir se
connecter au système de fichiers quand bon lui semblera. En effet, la
clé d’autorisation reste valable jusqu’à ce que le
système soit réinitialisé ou monté ailleurs. Un
client qui y a eu accès peut continuer à utiliser sa clé
d’autorisation avec succès, même si les contrôles
d’accès ont été modifiés dans le fichier
« /etc/exports » pour lui en interdire
l’accès.
Comme pour les systèmes Unix se pose le
problème des droits d’accès du root. Celui-ci peut avoir des
droits restreints au même niveau qu’un utilisateur normal, mais cela
ne constitue qu’une amélioration mineure, puisque n’importe
qui se faisant passer pour root sur une machine cliente peut se faire passer
pour un utilisateur de ce client, et donc posséder les mêmes droits
que n’importe lequel de ces utilisateurs.
Les serveurs NFS peuvent
également devenir sources de problèmes. En effet, un
système de fichiers monté par NFS peut contenir des programmes
setuid, ce qui peut permettre à un utilisateur du client de devenir
root.
6.3.1.B.1.b - NFS Sécurisé
:
Il existe un système NFS plus sécurisé, basé
sur Secure RPC. Ce système pose d’autres problèmes : il
n’est disponible que sur des machines Sun, le système
d’échange des clés entre les machines est délicat,
mais, surtout, il est peu performant.
6.3.1.B.2 - SAMBA :
Le projet SAMBA est un projet OpenSource permettant à une machine
Unix de partager des ressources (fichiers ou imprimantes) avec des clients
Windows. Les utilisateurs peuvent ainsi stocker leurs fichiers (même
d'importants exécutables) en un seul lieu pour en faciliter le partage et
la sauvegarde, sécurisés par des mécanismes Unix ou NT. Ce
projet implémente les mécanismes d’authentification et de
dialogue réseau des machines Windows. A ce titre il est sensible, outre
ses failles propres, à l’ensemble des attaques pouvant être
portées sur les serveurs Microsoft. A titre d’exemple, la
dernière alerte de sécurité concernant Samba date du 7
avril 2003 : elle permet l’obtention d’un accès
« root » sur le serveur Samba.
6.3.1.C - Les serveurs Netware :
Dans la plupart des grandes entreprises, les serveurs sous environnement
Novell Netware hébergent fréquemment des données
importantes (comptabilité, documents financiers ...). Le groupe IDC
recensait en 2000 environ quarante millions d’utilisateurs
raccordés à un serveur Novell Netware et 11.7% des nouvelles
licences serveurs acquises en 2001 par les entreprises étaient des
licences Netware. La société Novell compare ses serveurs à
Fort Knox mais de nombreux experts de la sécurité ne partagent pas
leur optimisme. En effet s’il est vrai qu’il est possible de rendre
ces serveurs relativement sûrs, la configuration par défaut de ces
serveurs présente un certain nombre de failles de sécurité.
Une des failles principales de Netware est la possibilité
d’établir un lien anonyme avec un serveur Netware
permettant :
- la récupération des noms d’utilisateurs ;
- la récupération de la composition des groupes
d’utilisateurs ;
- la liste des serveurs Netware connus ;
- la liste des volumes Netware et des queues d’impression
partagées.
Cette connaissance du réseau Netware
présente le désagréable avantage de fournir à
l’attaquant une liste de machines et de noms d’utilisateurs valides.
Novell fournit même (à l’attention de l’administrateur)
un outil permettant de détecter les utilisateurs ayant des mots de passe
nuls ou faciles à déchiffrer !!! L’utilisation de
logiciels d’attaque par force brute permet ensuite de finir par trouver le
mot de passe d’un utilisateur ayant des droits administrateur. Une fois
cet accès obtenu, tous les droits sont désormais
acquis !!!